Alternative to ..\{project}_Net45 folder side-side hack #1933
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
that allows to develop project.json (the toolchain that produces our artifacts) and csproj files (the best interface for continuous tests through NCrunch) in tandem. The old separate folder hack introduces strict restrictions on our csproj based solution, adding files was forbidden because this would expand the wildcards in the csproj and the file would end up in the wrong folder. Normally this side by side loading is riddled with nuget biting into both worlds but luckily we use paket in the csproj world. We didn't go for this solution initially because NCrunch while not supporting project.json, it did have an undocumented check for project.json files to kick off a different project resolution. Since NCrunch 2.20 (released yesterday) this "special" check is removed and NCrunch loads our csproj files that live next to project.json normally again. Our default work solution can now be Elasticsearch.sln again, while our command line build still builds Elasticsearch.DNX.sln and we can use the latter to investigate CoreCLR bugs/features.
Mpdreamz
added a commit
that referenced
this pull request
Mar 21, 2016
Alternative to ..\{project}_Net45 folder side-side hack
|
Awesome! LGTM 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
that allows to develop project.json (the toolchain that produces our
artifacts) and csproj files (the best interface for continuous tests
through NCrunch) in tandem.
The old separate folder hack introduces strict restrictions on our
csproj based solution, adding files was forbidden because this would
expand the wildcards in the csproj and the file would end up in the
wrong folder.
Normally this side by side loading is riddled with nuget biting into
both worlds but luckily we use paket in the csproj world.
We didn't go for this solution initially because NCrunch while not
supporting project.json, it did have an undocumented check for
project.json files to kick off a different project resolution. Since
NCrunch 2.20 (released yesterday) this "special" check is removed and
NCrunch loads our csproj files that live next to project.json normally
again.
Our default work solution can now be Elasticsearch.sln again, while our
command line build still builds Elasticsearch.DNX.sln and we can use the
latter to investigate CoreCLR bugs/features.